In order for the optical networking equipment of various vendors to interoperate efficiently, standard control plane protocols must be supported at the associated interfaces. In the International Telecommunications Union (ITU-T) Automatically Switched Optical Network (ASON) model, these external interfaces are the User-Network Interfaces (UNIs) and the External Network-Network Interfaces (E-NNIs). The external interfaces are typically based on RSVP, which is a standard defined by the Internet Engineering Task Force (IETF). In general, RSVP is a signaling protocol used in Optical UNI (OUNI) and E-NNI to reserve network resources between UNI clients end-to-end through the optical domain. RSVP is part of the Internet Integrated Service (IIS) model, which ensures best-effort service, real-time service, and controlled link-sharing. The RSVP definition includes basic procedures, messages, and object formats for signaling. At the same time, the internal control plane within the domain of a particular type of optical networking equipment runs its own internal control plane protocols, such as OSRP, with features and procedures that differ from the standards.
Existing standards do not specify how the above interoperability should be provided, but typically assume that there is some mapping between the messages and fields at the external interfaces. Examples include ITU-T Specifications G.7713, G.7713.1, G.7713.2, and G.7713.3, which define protocol-independent messages and parameters that may be used as a basis for mapping to the internal control plane protocols. Another example includes the Optical Interconnect Forum (OIF) Generalized Multi-Protocol Label Switching (GMPLS) Interworking draft document, which illustrates how mapping from the OIF UNI and E-NNI to an internal domain using GMPLS. Thus, the current state-of-the-art assumes that there is a message-by-message and parameter-by-parameter mapping from the external control plane protocol to the internal control plane protocol.
This detailed mapping of all of the protocol messages and elements results in an extremely close linkage between the external interface and the internal control plane protocol, making it difficult to use an external protocol that has different semantics, or requiring costly enhancements to the internal protocol such that it matches the mapping tables. Further, every time that a new feature is incorporated into the external protocol, the internal protocol must be changed to allow for mapping, thus adding cost and delay for development and testing, as well as potential for errors that may cause control plane failures. Mapping protocol messages and elements one-by-one from the external protocol to the internal protocol also adds considerable overhead due to the fact that some of the parameters in the external protocol have no counterpart in the internal protocol, yet it may be necessary to map these parameters back at the external interface of the remote end. Again, the internal protocol must be changed to allow for mapping, thus adding cost and delay for development and testing, as well as potential for errors that may cause control plane failures.
Further, RSVP requires that protocol sessions are periodically refreshed by repeating the original message or some summarized version thereof in order to keep a session alive. This requirement is unique to RSVP and is not associated with other protocols that utilize a more reliable lower layer, such as Transmission Control Protocol/Internet Protocol (TCP/IP) or Asynchronous Transfer Mode (ATM) ATM Adaption Layer (AAL). A straight mapping of these refresh messages introduces the potential for confusion in interpretation for the internal protocol, as well as additional protocol processing overhead and message traffic every time a refresh message is received.
Thus, what are still needed in the art are improved methods and systems for interworking RSVP-based external control plane protocols with internal control plane protocols, such as OSRP.